Many video editing products exist for capturing and editing multimedia content, such as video. Many of these products are software running on computing systems. Many of these products allow the user to render a final product for storage on tape, hard drive, CD-ROM, and DVD or for distribution over a network.
With these products, a user typically captures several video clips. When editing, the user builds a timeline of video clips, which the user has selected from the captured clips. At this point, it is a collection of video clips strung together on a timeline.
Transitions
Sometimes simple cuts from one clip to the next work well, but sometimes the cut is harsh and unappealing. Therefore, many video editing products offer the user the option to include a transition from one clip to another. Common examples of transitions include dissolves, wipes, and fades. Often using a drag-and-drop technique, a user selects a transition and the two clips to transitions between. For example, if the user chooses a fade-out/fade-in transition, clip one will fade-out and then clip two will fade-in.
The user needs not calculate how to perform such transitions. Rather, when the completed “movie” is rendered from the editing application, the video editing product calculates and renders the transitions from one clip to the next.
However, the user typically wants to see how this transition will appear without rendering the entire movie and encoding/archiving to a separate file-which can be time-consuming. Indeed, it is quite common for the user to want to see the transition nearly immediately after placing it into timeline of clips.
Glitchy Realtime Playback
If the user immediately watches just the portion of the movie with the new transition therein, the user might experience glitchy realtime playback. This is because the system is attempting to apply the transition in real-time during playback, when in fact the computations involved are too complex to be done in real time.
In those situations, user will see a glitch, interruption, jumpiness, or jerkiness in the video playback, or the video might just play back too slowly. In other words, the playback will not be smooth. Therefore, the user may believe that some error has occurred in the creation of the movie, but, in reality, it is only that the transitions cannot be computed on the fly in real time during playback.
It is a “realtime” playback because the intent is for the computer system to display the rendered playback video segment at the same rate or, at least, no slower than it decodes and renders it. Indeed, there is typically a normal decode schedule that specifies the normal rate for decoding a segment of video. Often the rendering and displaying a video segment matches the decode schedule. The realtime playback has a glitch when rate of rendering or displaying a video segment exceeds the rate of decoding that segment.
With some systems and in some situations, the momentary processing requirements for generating the newly inserted transitions between scenes and the processing requirements for realtime playing back the video may exceed the total available processing capacity.
In other words, the decoding and rendering of a video segment (including its transition) may require more than all of the available computing resources on a computer system at a given moment. An example of such a situation when one is attempting to play back a transition between two encoded video clips.
The chances of such a glitch occurring during a realtime playback increase along with the overall bandwidth of the video clips (which includes resolution and number of frames per second) and the complexity of the transform being applied. This is particularly true as high-definition (HD) television and video equipment is becoming increasingly more common.
The chances of a glitch also increase with the complexity of the transition being performed. It decreases with the overall processing power of the computer system doing the playback.
Conventional: Glitch-Free Playback
Some conventional video editing products do nothing to avoid the possibility of a glitchy realtime playback. They simply hope that computer processing power will exceed the processing requirements of realtime playback. However, as indicated above, that “hope” is slowing fading because the overall bandwidth of video is increasing (especially with the advent of HD video onto the market).
Some conventional products attempt to avoid the problem of glitchy playback by introducing a delay that removes the “realtime” aspect of the playback.
These conventional products pre-render the segment of video having the transitions therein. In other words, the product begins rendering the video segment having the transitions in anticipation of the user wishing to view that segment. So when playing back that segment, it shows the already pre-rendered segment.
“Pre-rendering” refers to writing a video segment to disk with transitions and effects applied so that this output can be played back without having to apply those transitions and effects in real time. Pre-rendering is a time-consuming operation that interrupts the users workflow.
To allow for pre-rendering, the user's playback is delayed. Therefore, it no longer realtime playback. Instead, the playback is based, at least in part, on pre-processing.
While that delay introduced by pre-rendering may be short, the user is prohibited from immediate playback. Indeed, that pre-rendering delay will only increase as the video bandwidth and the complexity of the transition does.
No conventional video editing product allows for immediate playback of video segments (with transitions applied therein) which is both glitch-free and realtime.